Base Page is a reusable foundation class used in Selenium automation frameworks to store common WebDriver functionality, reusable browser actions, synchronization methods, utility methods, and shared page-level operations. Instead of writing the same Selenium code repeatedly in every Page Object class, common functionality can be placed inside a Base Page and inherited by other page classes.
Base Page is commonly used together with the Page Object Model (POM). In a well-structured Selenium framework, the Base Page provides reusable functionality while individual page classes contain page-specific locators and business actions.
Course Resource: Selenium Training | Register for Course Demo
A Base Page is a parent class from which other Page Object classes inherit common Selenium functionality. It acts as a central location for reusable browser interaction methods.
For example, multiple pages may require operations such as clicking an element, entering text, waiting for an element, retrieving text, checking visibility, scrolling, selecting dropdown values, or navigating to a URL. Instead of implementing these methods separately in every page class, they can be implemented once inside the Base Page.
BasePage
|
+-- Common WebDriver Methods
|
+-- Wait Methods
|
+-- Click Methods
|
+-- Input Methods
|
+-- Navigation Methods
|
+-- JavaScript Utilities
|
+-- Screenshot Utilities
|
+-- Page Classes
|
+-- LoginPage
+-- HomePage
+-- SearchPage
+-- CheckoutPage
Large Selenium frameworks usually contain many Page Object classes. If every page class contains its own implementation of common browser operations, the framework becomes repetitive and difficult to maintain.
A Base Page solves this problem by centralizing common functionality.
The Page Object Model represents application pages as classes. Each page class contains locators and methods related to that page.
The Base Page sits above these page classes and contains functionality that is common to many or all pages.
BasePage
|
+----------+----------+
| | |
v v v
LoginPage HomePage SearchPage
| | |
+----------+----------+
|
v
Test Classes
This design helps separate common Selenium functionality from page-specific business logic.
A basic Base Page normally contains a WebDriver instance and reusable methods.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class BasePage {
protected WebDriver driver;
public BasePage(WebDriver driver) {
this.driver = driver;
}
public void click(By locator) {
driver.findElement(locator).click();
}
public void enterText(By locator, String text) {
driver.findElement(locator).sendKeys(text);
}
public String getText(By locator) {
return driver.findElement(locator).getText();
}
}
The protected WebDriver allows child Page Object classes to access the driver while keeping the field appropriately encapsulated from unrelated classes.
The constructor is responsible for receiving and storing the WebDriver instance.
public BasePage(WebDriver driver) {
this.driver = driver;
}
When a child page is created, it can pass the WebDriver to the Base Page constructor.
public class LoginPage extends BasePage {
public LoginPage(WebDriver driver) {
super(driver);
}
}
The super(driver) statement calls the parent class constructor and initializes the WebDriver stored in Base Page.
In a Page Object Model framework, the WebDriver is often declared as protected in Base Page.
protected WebDriver driver;This allows classes that inherit from Base Page to use the driver directly when necessary.
public class LoginPage extends BasePage {
public LoginPage(WebDriver driver) {
super(driver);
}
public void openPage() {
driver.get("https://example.com/login");
}
}
Clicking elements is one of the most frequently used Selenium operations. A reusable click method can be placed inside Base Page.
public void click(By locator) {
driver.findElement(locator).click();
}
A page class can then use this method instead of directly calling Selenium's click operation repeatedly.
public void clickLoginButton() {
click(loginButton);
}
A reusable method can be created for entering text into input fields.
public void enterText(By locator, String text) {
driver.findElement(locator).clear();
driver.findElement(locator).sendKeys(text);
}
Example usage:
public void enterUsername(String username) {
enterText(usernameField, username);
}
Applications frequently require validation of text displayed on the page.
public String getText(By locator) {
return driver.findElement(locator).getText();
}
Example:
String message = getText(successMessage);
System.out.println(message);
A reusable visibility method can be used to determine whether an element is displayed.
public boolean isDisplayed(By locator) {
return driver.findElement(locator).isDisplayed();
}
Example:
if (isDisplayed(loginButton)) {
System.out.println("Login button is visible");
}
Sometimes frameworks need to check whether an element exists without allowing a missing element exception to immediately fail the test.
public boolean isElementPresent(By locator) {
try {
driver.findElement(locator);
return true;
} catch (Exception e) {
return false;
}
}
For production frameworks, exception handling should be kept specific and carefully designed rather than catching overly broad exceptions unnecessarily.
Navigation methods can also be centralized.
public void navigateTo(String url) {
driver.get(url);
}
Example:
navigateTo("https://example.com");Common browser navigation operations can be wrapped inside reusable methods.
public void goBack() {
driver.navigate().back();
}
public void goForward() {
driver.navigate().forward();
}
public void refreshPage() {
driver.navigate().refresh();
}
A common utility method can return the current page title.
public String getPageTitle() {
return driver.getTitle();
}
Test classes can use this method for page title validation.
Assert.assertEquals(
loginPage.getPageTitle(),
"Login Page"
);
The current URL can also be retrieved using a reusable method.
public String getCurrentUrl() {
return driver.getCurrentUrl();
}
This is useful for validating navigation after login, search, checkout, redirects, and other workflows.
Synchronization is an important part of Selenium automation. Instead of writing explicit wait code repeatedly in every Page Object, common wait operations can be centralized in Base Page.
import java.time.Duration;
import org.openqa.selenium.support.ui.WebDriverWait;
public class BasePage {
protected WebDriver driver;
protected WebDriverWait wait;
public BasePage(WebDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(
driver,
Duration.ofSeconds(10)
);
}
}
A reusable visibility wait can improve test stability.
import org.openqa.selenium.support.ui.ExpectedConditions;
public void waitForVisibility(By locator) {
wait.until(
ExpectedConditions.visibilityOfElementLocated(locator)
);
}
The method can then be used before interacting with an element.
waitForVisibility(usernameField);
enterText(usernameField, "admin");
Some elements may exist in the DOM but may not yet be ready for interaction. A clickable wait can be added to Base Page.
public void waitForClickable(By locator) {
wait.until(
ExpectedConditions.elementToBeClickable(locator)
);
}
This can be combined with a click operation.
public void clickWhenReady(By locator) {
waitForClickable(locator);
driver.findElement(locator).click();
}
A framework can combine synchronization and interaction into one reusable method.
public void click(By locator) {
waitForClickable(locator);
driver.findElement(locator).click();
}
This keeps individual Page Object methods short and readable.
The input method can also wait for visibility before entering data.
public void enterText(By locator, String text) {
waitForVisibility(locator);
driver.findElement(locator).clear();
driver.findElement(locator).sendKeys(text);
}
Dropdown functionality can also be centralized when the framework frequently works with standard HTML select elements.
import org.openqa.selenium.support.ui.Select;
public void selectByVisibleText(
By locator,
String text) {
Select select = new Select(
driver.findElement(locator)
);
select.selectByVisibleText(text);
}
Example:
selectByVisibleText(countryDropdown, "India");JavaScriptExecutor can be wrapped inside reusable methods when a framework needs JavaScript-based operations.
import org.openqa.selenium.JavascriptExecutor;
public void executeScript(String script, Object... args) {
JavascriptExecutor js =
(JavascriptExecutor) driver;
js.executeScript(script, args);
}
A reusable scrolling method can be implemented in Base Page.
public void scrollToElement(By locator) {
JavascriptExecutor js =
(JavascriptExecutor) driver;
js.executeScript(
"arguments[0].scrollIntoView(true);",
driver.findElement(locator)
);
}
This can be useful when elements are outside the currently visible viewport.
Screenshot functionality is frequently required for failed tests and debugging. It can be centralized in a utility layer associated with the Base Page or framework utilities.
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
public byte[] takeScreenshot() {
TakesScreenshot screenshot =
(TakesScreenshot) driver;
return screenshot.getScreenshotAs(
OutputType.BYTES
);
}
The exact screenshot storage and reporting strategy depends on the framework.
Alert handling can also be wrapped in reusable methods.
public void acceptAlert() {
driver.switchTo().alert().accept();
}
public void dismissAlert() {
driver.switchTo().alert().dismiss();
}
public String getAlertText() {
return driver.switchTo().alert().getText();
}
Frames and iframes require switching the driver's context. Common frame operations can be placed in Base Page.
public void switchToFrame(By locator) {
driver.switchTo().frame(
driver.findElement(locator)
);
}
public void switchToDefaultContent() {
driver.switchTo().defaultContent();
}
Window and tab handling can also be implemented as reusable methods.
public void switchToWindow(String windowHandle) {
driver.switchTo().window(windowHandle);
}
public String getCurrentWindowHandle() {
return driver.getWindowHandle();
}
A mature Base Page can provide reusable methods for common WebElement operations.
| Method | Purpose |
|---|---|
| click() | Clicks an element |
| enterText() | Enters text into an input |
| getText() | Returns element text |
| isDisplayed() | Checks element visibility |
| isElementPresent() | Checks whether an element exists |
| selectByVisibleText() | Selects a dropdown option |
| waitForVisibility() | Waits for an element to become visible |
| waitForClickable() | Waits for an element to become clickable |
| scrollToElement() | Scrolls to an element |
| getPageTitle() | Returns the current page title |
| getCurrentUrl() | Returns the current URL |
Consider a Login Page that inherits common functionality from Base Page.
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage extends BasePage {
private By usernameField =
By.id("username");
private By passwordField =
By.id("password");
private By loginButton =
By.id("loginButton");
public LoginPage(WebDriver driver) {
super(driver);
}
public void enterUsername(String username) {
enterText(usernameField, username);
}
public void enterPassword(String password) {
enterText(passwordField, password);
}
public void clickLogin() {
click(loginButton);
}
public void login(
String username,
String password) {
enterUsername(username);
enterPassword(password);
clickLogin();
}
}
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class HomePage extends BasePage {
private By welcomeMessage =
By.id("welcomeMessage");
public HomePage(WebDriver driver) {
super(driver);
}
public String getWelcomeMessage() {
return getText(welcomeMessage);
}
}
The Home Page does not need to implement its own getText logic because that functionality already exists in Base Page.
public class SearchPage extends BasePage {
private By searchBox =
By.id("search");
private By searchButton =
By.id("searchButton");
public SearchPage(WebDriver driver) {
super(driver);
}
public void search(String keyword) {
enterText(searchBox, keyword);
click(searchButton);
}
}
The test class should focus on test flow and validation rather than low-level Selenium operations.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.Assert;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
public class LoginTest {
private WebDriver driver;
private LoginPage loginPage;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com/login");
loginPage = new LoginPage(driver);
}
@Test
public void validLoginTest() {
loginPage.login(
"admin",
"admin123"
);
Assert.assertTrue(
driver.getTitle().contains("Dashboard")
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
Base Page commonly uses object-oriented inheritance. Page classes extend Base Page.
public class LoginPage extends BasePage {
}
public class HomePage extends BasePage {
}
public class SearchPage extends BasePage {
}
This means the child classes can reuse methods defined by Base Page.
BasePage
|
+-- click()
+-- enterText()
+-- getText()
+-- waitForVisibility()
+-- getPageTitle()
|
+-- LoginPage
+-- HomePage
+-- SearchPage
Base Page can also help enforce consistent access to WebDriver operations. Instead of exposing every low-level operation throughout the framework, common actions can be wrapped inside meaningful methods.
public void click(By locator) {
waitForClickable(locator);
driver.findElement(locator).click();
}
Page classes can then use:
click(loginButton);rather than repeatedly implementing the complete Selenium interaction.
Synchronization is one of the most valuable responsibilities that can be centralized. Dynamic web applications may require elements to become visible, enabled, or clickable before interaction.
public void waitForVisibility(By locator) {
wait.until(
ExpectedConditions.visibilityOfElementLocated(locator)
);
}
public void waitForClickable(By locator) {
wait.until(
ExpectedConditions.elementToBeClickable(locator)
);
}
Centralized synchronization also makes it easier to update waiting strategies across the framework.
Some applications require more customized polling behavior. A framework can create reusable FluentWait utilities where appropriate.
import java.time.Duration;
import org.openqa.selenium.support.ui.FluentWait;
FluentWait<WebDriver> fluentWait =
new FluentWait<>(driver)
.withTimeout(Duration.ofSeconds(15))
.pollingEvery(Duration.ofSeconds(1));
Fluent waits should be used purposefully. A framework should avoid creating unnecessary waits that make execution slow or unpredictable.
It is usually preferable to keep test assertions in test classes, but Base Page can expose information needed for assertions.
public String getPageTitle() {
return driver.getTitle();
}
public String getCurrentUrl() {
return driver.getCurrentUrl();
}
public String getText(By locator) {
return driver.findElement(locator).getText();
}
The test class can then perform the actual validation.
Assert.assertEquals(
homePage.getPageTitle(),
"Dashboard"
);
Base Page and utility classes have different responsibilities.
| Base Page | Utility Class |
|---|---|
| Usually associated with WebDriver | Usually provides general-purpose functionality |
| Inherited by Page Objects | Often called directly |
| Contains page interaction methods | May contain file, date, Excel, configuration, or reporting utilities |
| Usually belongs to the Page Object layer | Usually belongs to the framework utility layer |
Common functionality suitable for Base Page may include:
Base Page should not become a dumping ground for every utility in the framework.
Generally, avoid putting unrelated functionality such as:
These responsibilities can be separated into dedicated utility, service, configuration, or framework classes.
A clean automation framework separates responsibilities between layers.
Test Layer
|
|-- Test scenarios
|-- Assertions
|
v
Page Object Layer
|
|-- Locators
|-- Page-specific actions
|
v
Base Page
|
|-- Common Selenium actions
|-- Synchronization
|-- Browser utilities
|
v
WebDriver
|
v
Browser
Base Page should contain generic operations, while Page Classes should contain application-specific actions.
For example, click(By locator) is generic and belongs in Base Page.
public void click(By locator) {
waitForClickable(locator);
driver.findElement(locator).click();
}
But login(username, password) is application-specific and should normally belong to LoginPage.
public void login(
String username,
String password) {
enterText(usernameField, username);
enterText(passwordField, password);
click(loginButton);
}
Some Selenium frameworks use PageFactory to initialize Page Object fields.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.FindBy;
import org.openqa.selenium.support.PageFactory;
public class LoginPage extends BasePage {
@FindBy(id = "username")
private WebElement usernameField;
@FindBy(id = "password")
private WebElement passwordField;
@FindBy(id = "loginButton")
private WebElement loginButton;
public LoginPage(WebDriver driver) {
super(driver);
PageFactory.initElements(driver, this);
}
public void login(
String username,
String password) {
usernameField.clear();
usernameField.sendKeys(username);
passwordField.clear();
passwordField.sendKeys(password);
loginButton.click();
}
}
Whether to use PageFactory or direct By locators depends on the framework design and team conventions. A framework should use one consistent approach rather than mixing patterns unnecessarily.
Using By locators with reusable Base Page methods is a common framework pattern.
private By usernameField =
By.id("username");
public void enterUsername(String username) {
enterText(usernameField, username);
}
This approach keeps locator definitions inside the page class while keeping interaction methods in Base Page.
Another design can accept WebElement objects.
public void click(WebElement element) {
element.click();
}
public void enterText(
WebElement element,
String text) {
element.clear();
element.sendKeys(text);
}
Both By-based and WebElement-based designs can be used. The important requirement is consistent framework design and reliable synchronization.
A practical Base Page can combine WebDriver, explicit waits, common actions, and navigation methods.
import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
public class BasePage {
protected WebDriver driver;
protected WebDriverWait wait;
public BasePage(WebDriver driver) {
this.driver = driver;
this.wait = new WebDriverWait(
driver,
Duration.ofSeconds(10)
);
}
public void click(By locator) {
wait.until(
ExpectedConditions.elementToBeClickable(locator)
).click();
}
public void enterText(
By locator,
String text) {
wait.until(
ExpectedConditions.visibilityOfElementLocated(locator)
);
driver.findElement(locator).clear();
driver.findElement(locator).sendKeys(text);
}
public String getText(By locator) {
return wait.until(
ExpectedConditions.visibilityOfElementLocated(locator)
).getText();
}
public boolean isDisplayed(By locator) {
return driver.findElement(locator).isDisplayed();
}
public String getPageTitle() {
return driver.getTitle();
}
public String getCurrentUrl() {
return driver.getCurrentUrl();
}
public void navigateTo(String url) {
driver.get(url);
}
public void goBack() {
driver.navigate().back();
}
public void refreshPage() {
driver.navigate().refresh();
}
}
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage extends BasePage {
private final By usernameField =
By.id("username");
private final By passwordField =
By.id("password");
private final By loginButton =
By.id("loginButton");
public LoginPage(WebDriver driver) {
super(driver);
}
public void login(
String username,
String password) {
enterText(usernameField, username);
enterText(passwordField, password);
click(loginButton);
}
}
Test Class
|
v
Create WebDriver
|
v
Create Page Object
|
v
Page Object extends BasePage
|
v
BasePage initializes WebDriver
|
v
Test calls page-specific method
|
v
Page Object calls BasePage methods
|
v
BasePage performs Selenium operation
|
v
Browser
|
v
Application
Base Page should generally not contain test data. Test data should be managed separately using Data Providers, configuration files, JSON, CSV, Excel, databases, or other appropriate sources.
Test Data
|
v
Data Provider
|
v
Test Method
|
v
Page Object
|
v
Base Page
|
v
Selenium WebDriver
This separation keeps the framework easier to maintain.
Base Page can work with tests that use TestNG Data Providers. The Data Provider supplies values, the test calls the Page Object, and the Page Object uses Base Page operations.
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
loginPage.login(username, password);
}
Base Page can provide reusable information that helps reporting and debugging, such as page title, current URL, screenshots, or descriptive action logging.
However, the complete reporting implementation is usually better kept in a dedicated reporting layer or utility instead of making Base Page responsible for all report management.
Frameworks may log common operations such as clicking, entering data, navigation, and waiting.
public void click(By locator) {
System.out.println(
"Clicking element: " + locator
);
waitForClickable(locator);
driver.findElement(locator).click();
}
In production frameworks, a logging framework such as Log4j or SLF4J can be used instead of System.out.println.
Reusable methods can provide meaningful error information while allowing the original exception to remain available for debugging.
public void click(By locator) {
try {
waitForClickable(locator);
driver.findElement(locator).click();
} catch (RuntimeException e) {
throw new RuntimeException(
"Unable to click element: " + locator,
e
);
}
}
Error handling should be designed carefully. Over-catching exceptions can hide the actual root cause of a failure.
In larger frameworks, screenshots can be captured automatically when a test fails. The screenshot mechanism may be implemented through listeners or reporting utilities rather than putting all failure-handling logic inside Base Page.
Test Failure
|
v
TestNG Listener
|
v
Screenshot Utility
|
v
Capture Browser Screenshot
|
v
Attach to Report
Common browser-level operations can be grouped together.
| Operation | Example Method |
|---|---|
| Open URL | navigateTo() |
| Go Back | goBack() |
| Refresh | refreshPage() |
| Get Title | getPageTitle() |
| Get URL | getCurrentUrl() |
| Click | click() |
| Enter Text | enterText() |
| Get Text | getText() |
| Wait for Visibility | waitForVisibility() |
| Wait for Clickable | waitForClickable() |
| Base Page | Page Class |
|---|---|
| Contains common functionality | Contains page-specific functionality |
| Usually inherited | Usually represents a specific application page |
| Contains reusable Selenium operations | Contains page-specific locators and workflows |
| Should be generic | Can be application-specific |
| Shared across multiple pages | Used for one page or page component |
| Base Page | Test Class |
|---|---|
| Browser interaction utilities | Test scenarios |
| Common waits | Assertions |
| Reusable Selenium actions | Test data usage |
| Navigation helpers | Test execution |
| Page-level infrastructure | Validation and expected behavior |
A scalable Selenium TestNG project can separate Base Page, Page Objects, tests, utilities, and test data.
src
|-- test
|-- java
|-- base
| |-- BasePage.java
| |-- BaseTest.java
|
|-- pages
| |-- LoginPage.java
| |-- HomePage.java
| |-- SearchPage.java
| |-- CheckoutPage.java
|
|-- tests
| |-- LoginTest.java
| |-- SearchTest.java
| |-- CheckoutTest.java
|
|-- data
| |-- LoginDataProvider.java
|
|-- utilities
|-- DriverFactory.java
|-- ConfigReader.java
|-- ScreenshotUtil.java
|-- ExcelReader.java
|-- WaitUtil.java
Base Page and Base Test are different concepts.
Base Page provides common Page Object and Selenium interaction functionality.
Base Test commonly manages test-level setup and teardown, WebDriver lifecycle, configuration, and common test initialization.
BaseTest
|
+-- WebDriver Setup
+-- Browser Configuration
+-- Test Setup
+-- Test Teardown
|
v
Test Class
|
v
Page Object
|
v
BasePage
|
v
WebDriver
In larger frameworks, WebDriver creation can be separated into a DriverFactory.
DriverFactory
|
v
Create WebDriver
|
v
BaseTest
|
v
Test Class
|
v
Page Object
|
v
BasePage
This separation is particularly useful when supporting multiple browsers, environments, or parallel execution.
Base Page should normally remain independent of a specific browser. It should work with whichever WebDriver instance is supplied to it.
ChromeDriver
FirefoxDriver
EdgeDriver
|
v
WebDriver
|
v
BasePage
|
v
Page Objects
This allows the same Page Object classes to work with different browsers.
When Selenium tests execute in parallel, each test thread should have an appropriately isolated WebDriver session. Base Page should not introduce unsafe shared static driver state.
Thread 1
|
+-- WebDriver 1
+-- BasePage 1
+-- LoginPage 1
Thread 2
|
+-- WebDriver 2
+-- BasePage 2
+-- LoginPage 2
This design helps prevent one test thread from interfering with another.
Consider an e-commerce application containing Login, Home, Product, Cart, and Checkout pages.
BasePage
|
+-- LoginPage
|
+-- HomePage
|
+-- ProductPage
|
+-- CartPage
|
+-- CheckoutPage
Base Page can provide:
ProductPage can provide product-specific actions such as selecting a product, choosing quantity, and adding the product to the cart.
LoginTest
|
v
LoginPage.login()
|
+-- enterText(username)
|
+-- enterText(password)
|
+-- click(loginButton)
|
v
BasePage
|
v
WebDriver Actions
|
v
Browser
Automation Framework
|
+--------------+--------------+
| |
Test Layer Page Layer
| |
Test Classes BasePage
| |
| +----------+----------+
| | | |
| LoginPage HomePage SearchPage
| |
+------------------+
|
v
WebDriver
|
v
Browser
|
v
Application
Base Page is a reusable parent class that contains common Selenium and WebDriver functionality shared by multiple Page Object classes.
It reduces duplicate code and provides a centralized location for common browser interactions, waits, and page-level utilities.
Common methods such as click, enterText, getText, waits, navigation, title retrieval, URL retrieval, and other reusable browser operations can be stored there.
Passing WebDriver allows the Base Page and its child Page Objects to operate on the same browser session.
A protected WebDriver can be accessed by classes that inherit from Base Page while avoiding unrestricted access from unrelated classes.
Generally, no. Page-specific locators should remain in the corresponding Page Object class.
Generally, no. Test data should be maintained separately using appropriate data-management mechanisms.
Yes. Centralizing common wait operations is a common framework design.
Base Page provides common Page Object and browser interaction functionality, while Base Test commonly manages test setup, teardown, and WebDriver lifecycle.
Yes. If it works with the WebDriver interface rather than a specific browser implementation, the same Base Page can support different browsers.
Yes. Data Providers can supply test values to test methods, which then use Page Objects and Base Page methods.
Generally, assertions are better kept in test classes, while Page Objects expose information required for validation.
It can provide screenshot functionality, although mature frameworks often place screenshot handling in a dedicated utility or listener.
Yes. Common alert and frame operations can be provided as reusable methods.
The main advantage is centralized reusable functionality that reduces duplication across Page Object classes.
A common mistake is putting too much unrelated functionality into Base Page, turning it into a large and difficult-to-maintain class.
Common browser operations can be updated in one place rather than duplicated across many Page Object classes.
Yes. Page Objects can extend Base Page and use PageFactory for initializing WebElements if that approach is selected for the framework.
It can centralize explicit wait methods so Page Objects use consistent synchronization logic.
New Page Objects can inherit common functionality instead of implementing the same Selenium operations repeatedly.
| Concept | Description |
|---|---|
| Base Page | Reusable parent class for Page Objects |
| WebDriver | Browser automation interface used by Base Page |
| Constructor | Receives and initializes WebDriver |
| click() | Reusable element-click operation |
| enterText() | Reusable text-entry operation |
| getText() | Retrieves element text |
| waitForVisibility() | Waits until an element is visible |
| waitForClickable() | Waits until an element is clickable |
| getPageTitle() | Returns current page title |
| getCurrentUrl() | Returns current URL |
| Page Object | Represents a specific application page |
| Base Test | Common test setup and WebDriver lifecycle layer |
| Driver Factory | Centralized WebDriver creation mechanism |
Base Page is an important architectural component of a maintainable Selenium Page Object Model framework. It acts as a reusable parent class that contains common WebDriver interactions, synchronization methods, navigation functions, and other generic page-level operations.
Instead of implementing click, text input, waits, navigation, and other common operations separately in every Page Object, these operations can be implemented once in Base Page and inherited by LoginPage, HomePage, SearchPage, CheckoutPage, and other page classes.
A good Base Page should remain generic, focused, reusable, and easy to maintain. Page-specific locators and workflows should remain inside individual Page Object classes, while test scenarios and assertions should remain in test classes.
When combined with Page Object Model, Data Providers, Driver Factory, TestNG, reporting, logging, and CI/CD, Base Page can become an important part of a scalable Selenium automation framework.
Learn Selenium WebDriver, TestNG, Page Object Model, automation frameworks, data-driven testing, reporting, and related automation concepts through the Selenium training resources.
Final Takeaway: Base Page provides a common reusable foundation for Selenium Page Objects. By centralizing WebDriver operations, synchronization, and generic browser interactions, it reduces duplicate code and helps create a cleaner, more scalable, and maintainable automation framework.
